INTERACTIVE DESIGN COORDINATION FOR THE
Janes N. Jackson
MAC Technical Memorandum 10
Massachusetts Institute of Technology
Unnumbered Blank Page
Note: This page is an unnumbered
blank used to preserve the printed
appearance of the author's original
document. It is the back side of the
previous numbered page.
g».*V' 'TPW^p;^^:,- ■,:
In -tmrmut Iv* QMMIID. CflOfd 1 Mil gfl ■ jftfc lfr&
Bull dim I ndust ty
Techn I cal Mefnorane'um
. ■' ' b y v ■'
James N. Jackson
June 22, 1970
Department of CIW1 Enflneertni
Nasiaetiutetts 1 net! tate of Techno 1o«y
Unnumbered Blank Page
Note: This page is an unnumbered
blank used to preserve the printed
appearance of the author's original
document. It is the back side of the
previous numbered page.
The problem of effective communication in the process
of building design and construction is widely recognized.
The involvement of several design disciplines combined with
the tendency for designers to work in distinct offices
results in little capacity for them to investigate the
Influence of their design decisions on other design areas.
One of the responses to the need for effective
interaction in the use of computers for a design project Is
the supersystem concept proposed for I CES, the I nte^rated
Civil Engineering System. The supersystem Is defined as the
cooperat ive effort on the part of the designers of several
problem oriented computer capabilities to implement project
oriented capabilities by allowing each of their problem
oriented subsystems to reference a single file of project
data. The supersystem would allow design interaction by
having each of the problem oriented computer subsystems
reference a single file of information specifying the
Future work in the application o^ computers to
interactive and project oriented design in the building
industry will have to concentrate on the file structure to
be used in the impl ementat ion of a computer building Jesi xn
Tfie w6rk dl«§icr1%«cr herein :-*•*;* sirpsorte* by the Of flee
fcf «%v*1RaSear en under* extract NO0Ot^6f?*^-O276-O002. The
3: *a*fe%rth *s bet n« bain* ©arrletf oat as a Ph^*>i • thesis I n -the
..: f -
CfWl fhslheeftnt Systems Laboratory of the 1*part<n«»nt of
^ ^8fvH Engineering, Maasiehusettt institute o* Technology.
lst ^e researeft has been supervfset by Professoi- Kenneth F.
The process of building design and construction
involves much handling and manipulation of data. What
starts out as the single desire of a client for a building
develops into a full set of working drawings and specifi-
cations by the end of the design Qhase of the process and
ultimately finishes as an existing builling. When one
examines the data flow in the building process in light of
the data manipulating and storage capabilities of the modern
electronic digital computer, one expects at first to find a
broad utilization of the computer throughout the building
industry. Yet when one examines the degree to which
computers are actually used in the building process, the
findings are generally very disappointing. Few of the
design disciplines involved with the building process make
any significant use of the computer and even in these few
instances, the applications are in completely isolated
areas. While many design areas involved in building design
have been considered for computer implementation, most
efforts have been at the proposal stage only. The two major
exceptions have been the areas of structural analysis and
construction project scheduling for which large scale
systems have been implemented.
The reasons for the pattern of usage that one finds
reflect problems both of economics and degree of difficulty.
As would be expected, engineers have attacked those problems
first that seemed most promising of solution. Since both
structural analysis and construction scheduling arp quite
straightforward in an analytical sense and require much data
processing, they were computerized first. More significant,
however, is the fact that these two areas are the exclusive
domains of two distinct segments of the building process,
the structural engineers and the contractors. Each invested
in the software which It felt would make its operations more
efficient. Neither was particularly motivated to spend
money to make the job of someone else more efficient.
The reasons for this pattern of usage can also be
found in the approach taken by designers of computer systems
to the whole question of information. The techniques for
information handling developed for the analytic problem-
solving systems have in the past almost never considered
Information requirements beyond the scope of the system
being implemented. There has been little motivation to
consider the information requirements of other systems
because, first, there were few enough of these systems
Implemented on the computer to begin with, and secondly,
there had simply been no co-ordination which would result In
the information being used even if it were made available.
Furthermore, information has generally been structured so as
to optimize processing in view of the algorithms used by the
subsystem structuring it.
Information has always been considered as a static
collection of data values which were inout at the beginning
of a computer run and completely pursed from the computer at
the end of the run. There has been almost no attemnt to
view information from the point of v i r>w o f the project, as a
highly structured complex which starts as a single ilea an 1
which ends after great development as an extremely complex
set of drawings and specifications. In those few instances
where data has been organized by a computer system on
secondary storage, it has been done in such a way as to be
of use only to the system which so organized it.
Building data management, then, is an attempt to
solve the very complex problems of automating the flow of
information between various problem oriented comouter
capabilities used in the design and construction of
buildings, computer capabilities both existing and proposed.
Building data management is the concent of data transfer
applied to the realm of building systems. Data transfer
attempts to make It possible for independently conceived and
independently executed computer systems to communicate their
results with each other.
The concept of data transfer is not a new one. The
designers of ICES, an acronym for the INTEGRATED CIVIL
ENGINEERING SYSTEM (1), have attacked the problem t t -Int.?
trnnsfer from the very beginning of their effort. The ICES
system was visualized as a computer oriented system used bv
a collection of problem oriented subsystems (2). The
analogy was made to a wheel in which the system comprised
the axle/ the various subsystems the spokes, and lata
transfer was to have been a kind of rim uniting all of the
subsystems via communications capabilites (see Figure 1-1).
However, If one examines Ices System Hasten (3), the
guiding ohilosophy for the ICES system, one discovers that
there are two areas of the system that were not generally
implemented. They are the relational data structure
capabilities CO and data transfer. For several years much
work was put Into the Implementation of both of these areas.
While some results were obtained in the former area (5), no
real working system of any capability resulted In the
In the first efforts to implement data transfer, the
ICES researchers attacked the general problem of Information
flow within the computer. The work was motivated by their
strong feeling that subsystem designers should be given full
freedom for design of in-core data structures most suited to
the problem and algorithms with which they were working.
Yet, when these Independent systems attemoted to each solve
a different aspect of the same project, the need arose for
them to communicate results with each other. The early work
resulted in a proposal for a Oata Teftnftion Language (6),
but most felt that an appropriate solution to the problem
was still yet to be found. In the interim, of coure, data
transfer was actually acomplished by having the engineer
using the various subsystems on a project manually transfer
information from the printout of one set of results to the
problem language input of the second subsystem (See Figure
In 1968, Lons (7) performed a study of the efforts in
data transfer in the context of the ICES system. His major
conclusion was that while the attempt to solve the problem
of general data sharing between computer systems had borne
little fruit, there was some reason to be hopeful th^t a
less general approach to the problem mi ^ht give bettor
results. He distinguished between the concepts of the
system and the subsystem and introduced the concent of a
supersystem. The system is comprised of those capabilities,
generally oriented toward strictly comouter tasks, tint ar^
used by all of the subsystems. Subsystems are comprised o^
capabilities oriented toward some specific engineering
problem area. The suoersvstem is tiffined as a ijroun of
loosely organized subsystems, each oriented toward a
specific problem area, but jointly working towar I ths soal
of a project implementation, principally by sharing a common
data base stored permanently on a secondary storage device.
It is the matter of the orientation, problem versus project,
that distinguishes a subsystem from a supersystem. Thus,
while STRUDL, the structural design language. Is capable of
analyzing and selecting members for the structural frame for
a building, it is not capable of taking the entire hulldln?;
project or even the structural part from inception to
completion. The building design comprises many problem
areas, each of which might require a subsystem of the slz?
and complexity of STRUDL.
The implementation of data transfer is imoortant not
only for the concept of a supersystem but for the way that
engineering is practiced. Engineers, while in school, solve
problems. Each problem is a close look at some small,
specific engineering task. When the problem is solved, the
answer is graded and no more is done with it. Fnr.tneers, as
practicing professionals, work on projects. They, too,
solve problems. In distinction to the work of students,
however, the answers to their problems are integrated Into
the larger project effort. These answers are considered In
their ramifications with other "answers" for other problem
areas of the project and must be considered as part of all
the project data.
Computer efforts in engineering to date hive been
aimed at giving nroblem solving capabilities. And just as
looking at an engineering project as a series of problems
fragments the concept of a project effort, so have these
computer capabilities tended to fragment the work that can
be done for a project with a computer. This can be observed
In the tendency of engineers to require that a problem be of
sufficient size or complexity In order to justify solving it
with a computer. The fragmentation hss put an artificial
barrier between the engineer and his problem solving tool.
Now in order to overcome the tendency toward
f ragmentat Ion, in order to develop project oriented computer
capabilities or supersystems, the whole approach of
engi neer in? computer development must be re-examined.
Engineering computer technologists can re-orient the! r
efforts and work toward the development of project oriented
subsystems - unique, al 1 -encompass i ng computer systems.
These would be large scale efforts and might well result,
for example, in a STRUDL-like subsystem for bridge design,
another STRUDL-like subsystem for building design, a third
for tranmission tower system design, and so forth. The
difficulty with this approach Is the duplication of effort
that is required to develop unique subsystems for each
project area. The development of the STRUDL subsystem as a
problem oriented capability extended over five years. The
duplication of that effort several times for different
project areas is worthy of little consideration.
Another approach to implementing project oriented
capabilities is specifically that of the supersystem. Each
project area would have not a unique computer capability but
rather a unique project data structure. Thus computer
subsystem developers would continue their current
orientation of developing problem solving capabilities.- But
PROJECT AREA I
PROJECT AREA 2
each of these problem solving capabilities would have
additional, satellite features that would allow for the
implementation of data transfer between the subsystem and a
specific project data file. The existing subsystem would be
Integrated with a new supersystem by the implementation of
the satellite data transfer capabilities for the new project
data file (See Figure 1-3).
IhS. Bui Idine Industry
In the United States, the estimate for the total
value of construction durine; the year 1970 is set at $90
billion (8). Table 1-1 gives a breakdown by project type of
the estimated value of building construction during the same
year but excluding one and two family dwellings. The same
estimate predicts a greater than 109 percent increase In
construction value during the decade 1970-1980 to a value of
$193 billion. The estimate of the gross national product of
the United States for the years 1970 =ind 1980 given by the
estimate are $900 billion and $1,980 billion resoect 1 vely .
Furthermore, in the United States the industry is comoose:!
more than 900,000 contractors and 1,500,0^0
subcontractors employing over 3,000,000. They are
supplied by a myriad of other Industries employing
large numbers, such as the 2«+0,000 employees of
sawmills and planning mills, the 60,000 In millwork
and related products, and the 260,000 who manufacture
equipment. To handle financial, insurance, and real
estate dealings requires another 1,100,000 people of
whom more than 6u0,000 are In real estate alone. The
TABLE I-] (9)
Forecast of Construction Contracts - 1970
Mill Ions of Dol lars
Total Construction * $52,225
Heavy Construction $16,875
Non-Residential 3ul Iding 26,10
Government Servi ces 1,000
Recreational, Religious, Etc 2,700
Residential * 9,25
Hotels and Motels 750
* Excludes one and two families dwellings.
building design professions incl ude 30,000 registered
architects and 75,000 engineers plus a large number
of specialists. Manifestly the industry is lar^e but
diffuse, and consists of a loose agglomeration of
mostly small units. The number of design-
construction firms with an annual volume greater than
$500 million can be counted on the fingers of one
hand. Few materials and equipment producers rank
among the nation's 500 largest industrial firms. (10)
The technical areas required in the design and
construction of a large building are amazingly diverse. One
can consider the professional and economic interests of the
building industry as falling into one of four general
categories : management, design, construct Ion, and f i nal 1 y
operation and maintenance.
The realm of management includes, first of all, the
cl lent or owner. The cl i ent is the prima movens of the
entire industry. It is he who dictates the kind and quality
of building depending on his needs and financial backing.
Owners range In size from the private, single home builder
through developers of capital investment motivated
skyscrapers in large metropol Itan centers and the Federal
government with all of Its resources.
Included in the realm of economics, however, are many
other professions concerned with building. These include
planning boards for urban areas, financiers (including
banks, insurance companies, pension and welfare funds, and
government mortgage financing agents), real estate
developers, zoning commiss ions, accountants, and the like.
The second realm of the building Industry is that of
design. Traditionally, the management of design h=js been in
the hands of an architect who acts as the client's agent for
both design and construction. 3ut iue to the wMely
divergent and highly technical nature of many asoscts of
building desicrn, the architect (excluding one an.1 two
dwelling housing, which represents about one-half of the
construction dollar value) requires the assistance of
professional consultants in the engineering areas. Thesp
generally include the structural engineer, the foundation
engineer, the mechanical engineer, the electical engineer,
and specialists in the areas of cost estimating, interior
design, acoustics, illumination, and landscaping.
The third realm of the industry is that of
construction. The construction phase of the building
project has traditionally been managed by the architect, but
the prime agsnt here is the general contractor. The general
contractor, like the architect in the design realm, uses
specialized sub-contractors to perform the highly technical
phases of the construction. These sub-contractors include
plumbers, heating and air conditioning specialists,
electrical contractors, plasterers, stone masons,
carpenters, roofers, structural steel erectors, and
foundation contractors, among others.
The final realm is that of operation and maintenance.
Included here are the operations engineers required to keep
large mechanical and electrical systems for buildings
functioning properly/ cleaning crews, security personnel,
and the construction trades required for repairs and
modi fi cat ions.
It should be clear that this diversity of economic
interests and intellectual disciplines involved in the
building industry lead to a fragmentation that exists on
three levels. There is a f ragmentat i on of personnel. The
nature of building design alone is such that one can never
expect to see a single person being able to do the entire
design. There Is a fragmentation of location. For the most
part as the profession is currently carried on, the
participants In the design and construction stages each have
separate offices, sometimes even to the extent of being
located In different cities. And finally, there is a
fragmentation of goals. What may well be the best
structural design can lead to a definitely sub-optimal
mechanical design, and vice versa. What appears best in
terms of initial cost may be very poor when considered in
terms of long term costs.
The major consequences of this fragmentation ar&
three. By far the most important and at present the most
widely recognized consequence Is the communication problem.
Communication is a basic aspect of the design and
construction of buildings, whether all of the design
participants work in a single office or not. The range o^
design disciplines dictates that professional interaction
take place. The building process typically starts as the
desire of a client for a building and is developed through
interviews between the client and the designer, through the
various design stages, to a fully developed set of contract
drawings and speci f I car ions . A second consequence of
fragmentation and one that follows also from the
communication problem is that of sub-optimization of design.
A less than perfect communication between the principal
designers makes it impossible to estimate how their design
decisions affect each other and consequently how such
decisions affect overall cost for the client. The problem
of optimization in building design is as much a matter of
communication as it is of mathematics. And finally, a last
consequence of fragmentation is duplication of effort. As
currently practiced / the duplicate review of drawings and
specifications for cost estimating by architects and bi-Min-
by contractors is typical of this duplication of effort.
Consider the kinds of Incidents that occur in the
current state of building design. The structural and
mechanical engineers, having arrived at initial, compatible
configurations for the structural frame an:i duct system,
return each to his own office where detail design continues.
Later the architect informs the mechanical engineer that
certain changes have occurred in the specification of
materials for an irea, thus changing the heat loads and
requiring in turn a ]arF,er duct servicing the area. If the
mechanical engineer fails to confer with the structural
engineer again, as happens sometimes when the design is
rushed, the conflict surfaces only when the contractor
discovers that the duct is supoosed to go through a
One of the reactions to this fragmentation has been
the tendency of late to combine in one firm all of the
principals involved in the building industry - financier,
architect, engineers, and contractor. This reunification at
least within the same firm helps alleviate some of the
problems resulting from the fragmentation. Many of the
goals are thereby consolidated and the problem of
communication is generally that much lessened.
The supersystem concept discussed above is another
reaction to this problem of fragmentation. The supersystem
proposes to consolidate all of the information about a
project in a central file of data where it is available to
all design participants at the same time. Furthermore, the
availability or data to all designers potentially allows for
studying the effects of design decisions made in one design
area on the other aspects of the overall lesion. Thus
engineers can design in terms of overall project goals
rather than the more immediate goals of just their own
discipline area. Finally, the devel ooment of
telecommunications for computers whereby engineers using
only low cost terminals in their offices can use the power
of large computers and data files literally across the
country, will help in the matter of locational fragmentation
where it continues to exist,
jh& Building Process
Having viewed building construction from the
viewpoint of an industry, one can take a slightly different
approach and view the same thins from the viewpoint of a
process. Considered as a process, building is composed of
The Royal Institute of British Architects (11) has
Identified twelve stages of building activity. These stages
are only an attempt to give a general classification to the
phase of activity most prevalent at the instant, and there
is no claim that there are distinctly recognizable points of
transition between the stages or that all designers are even
in the same stage at the same time. The phases of the
building process Identified by the Institute are:
Inception - First meetings with client and
establishment of design team.
Feasibl 1 Itv - Preparat ion of first outline from
interviews with client and assurance that outline is
Out! ine Proposal - Further detailed study of client's
requirements, costs of project, and approaches to
layout, design, and construction.
Scheme Design - Final development of preliminary
design, including full design by architect and
preliminary design by engineering designers.
Deta i 1 Pes i gn - Final dec i s ions on all des i gn
Product i on I nforma t ion - Preparation of final design
d rawi ngs and specifications.
Bills of Quanti t ies - Preparation of Tills of
Quantities for construction bMs.
Tender Act ion - Bid ii ng by gera ral contractors.
Project Plann i ng - Construction co-ordination between
general contractor and his sub-contractors.
Qperat ions on Si te - Actual construction.
Comol et i on - Completion of construction.
Feed-back - Anal ys i s of des i gn, const ruct i on, and
operation of building during its life.
Thisdistinction between various phases of the
bui 1 di ng process is important. Clearly, the probl ems an*1
even the nature of communi cation differ during the various
phases of buil di ng. At inception, ideas and data are few,
highly unorganized, constant 1 y changing, and even geometry,
a fundamental aspect of all building data is in a very fluil
state. By the start of preliminary design, most of the
geometry has firmed up, and the real problems of
commun ication and interaction among des i priors become the
most important aspects of the information. "y final design,
the sheer vol ume of i nfornat ion has become its most critical
aspect and it is that aspect which extends through the
construction phases. It is this evolving characteristic of
but 1 ding i n format ion (the same hoi ds for the i nfornat ion for
any engineering project) that makes the subject of oroject
data management such a difficult one. These sane changing
characteristics will dictate explicit requirements for any
attempt at automated data management as will become evident.
Why LLs£ Computers In Dl£ ?MJ1dinfi PrQCSSS
The very fundamental question of why the computer
should be used at all in the building process is one that
should be faced. In this age of mass computerization it
might seem strange that such a question be phrased/ but as
the complexity and cost of proposed computer systems grow,
more and more are coming to ask just that question.
The computer with its allied software is just another
among many potential tools for those engaged In the building
process. Recause of its tremendous potential for extremely
fast calculations and larse capacity data man I oul 3t ion,
however, the computer stands as a particularly significant
tool in the collection of the building designer and
contractor. As Miller has stated it:
Computers are the key to a systems approach
to civil engineering. The nature of contemporary
projects is so lar»o, and there are so many complex
factors and components - all these different kinds of
Information must be tied together, and the only way
you're going to do it is by computer. I f m talking
about using computers as I nf ormat ion management
devi ces and not as merel y computat ional tool s. Onl y
about 10% of our probl ems are computat ional by
nature, the other 90% are problems of Information
storage, control, and manipulation. (12)
There is little question of the computer's canablltty
to store information. Consider, for example, the IBM
System/360, Model 65, computer. Configured with one million
bytes of core storage, a model 2301 drum unit, a model 2 3 1 *#
disk stroage unit, and a model 2321 data cell drive, such a
system has nearly 500 million characters of on-lin-* storage:
one million characters of the storage can be accessed in
less than one microsecond; five million characters of
storage can be accessed in less than ten milliseconds; over
sixty million characters of storage can be accessed in less
than one-tenth of a second; and all of the nearly one half
billion characters of storage can be accessed in just over
one-half second (13). Understandably, no one yet really has
any feeling of how many characters of data would be required
to completely describe a building design. But there Is
little doubt that the computer will meet the task, at least
as regards capacity. The situation looks even more hopeful
with speculation that the next generation of computer
hardware will improve the cost/performance ratio of computer
systems by a factor of from six to twelve over the last
generation of hardware (14).
Context qL t±L£ Current Effprt
The task of developing automated data transfer for
the building industry is truly a monumental one. The size
and complexity of the industry combined with the range of
disciplines that are involved in financing/ designing, and
constructing buildings has lead to much hesitancy to even
attempt to tackle the problem. Clearly no one effort will
be completely successful in such an undertaking and the
current wotk is just the beginning of what will have to be a
long process of research and evolution. The current effort
has been as much an attempt to further define the problem as
it has to develop a working solution. One of the things
that has become clear is that the solution will be an
evolutionary process rather than a completely developed
working capability from the start. In the current effort,
also, the concentration has been placed on the communication
of data between engineers concerned with the design of
buildings, rather than architects or the construction or
operation phases of the building process. The reasons for
the emphasis on the engineer rather than the architectural
aspects of design are twofold. First, the author is in
engineer rather than an architect. But more si p;ni f icantly,
architecture is an atheoretical discipline. An architect
considers himself to be an artist working in a technical
industry. The consequence of this is that architects
structure and treat data differently from the way engineers
do. Hence/ while the designers of an architectural computer
system might not be completely happy with the file structure
of information that will be considered later, their system
could still be capable of feeding Information regarding
geometry and materials to the data base. These two
Information areas are key components in many of the
engineering design areas.
There are two major areas to be investigated in the
implementation of an ICES building design subsystem: data
management and file structure.
The concept of using data as the integrating bond for
a building system leads directly to the fundamental question
of data management. The general problem of data management
has been the object of much computer research and
development over the past decade. The levelooment of the
generalized data management systems leads one to consider
their value for the problem of data management in the
building context, or at least the approorl ateness of their
approach to a solution for this problem.
The generalized data management systems have
addressed themselves directly to the problem of how does one
manage the computer environment where there exists a large
corpus of data about some loosely structured logical entity
(generally a corporate or military operation) which must b«
developed and used by a group of independent computer
systems, none of which is responsible for all of the data
and all of which must share the use of the data. This is
exactly the problem faced in the building realm.
While the use of the feneral i ze i data management
systems in the context of building systems has s.tmp
drawbacks, the ICE? systems as currently implemented does
Uave some data management capabilities. The * C F ^ TABLE- li
system has file structure capabi 1 i ti es and storage and
The TABLE- 1 I file structuring capabilities are
particularly appropriate for the problem of storing dynamic
information in a file on secondary storage. This system,
like the general i zed data management sys terns, stores
information in such a manner that its location and
character! sties are remembered by the system. Further no r? ,
lata are identified by name in such a way that o:*ie need
merely provide the system with the name and the system is
able to retrieve not only the value but also information as
to what the characteristics of the data ar(> (dimensional
uni ts and computer characteristics). Concent ual 1 y, the
i nformat ion is structured as a four level tr^e: table, r<v-/,
column, and list position.
The feature of having available a file system which
uniquely identifies and manages data within the system is o r
primary importance in the area of build inn; systems (as we "' I
as many other systems ) . The problems of mana» 7 j n?. a growi np
corpus of information used by completely indeoendent
computer systmes demands that one consider only a data
management system capable of treating the information as a
growing, dynamic entity. The classical approach of file
structure based on locational conventions is clearly out of
the question in such a situation. Such an aoproach always
demands a fixed file large enough to hoi. I the largest anount
of data one can design for. Furthermore, it is generally
impossible to identify the condition where data values art*
missing - where they have not been stored yet. The
integration of various computer systems for different
discipline areas requi res that i nformat ion regard in?
dimensional aspects of the data be maintained as well as the
convenience of automat ic con vers ion of d (mens ions on
The TABLE-II system has the additional feature that
there are currently available a collection of storage and
retrieval f unct ions for pass! ng i nformat ion in 31 the r
direction between an engineering program and a secondary
storage file. The TABLE-II subsystem is rather unique amnns
the ICES subsystems: it exists on both the emri nee r-user
level as a problem oriented lan<\uae;e subsystem and on the
programmer-user level as the collection of stora.se and
retr ieval f unct ions .
The file structure for a computer based information
system must closely reflect the structure of the dotn .&§. j _t
is used bv the designers. The file structure for a building
information system must be based on the characteristics of
the use of data by the engineers and the architect. Each of
these people has a responsibility which is uniquely his own.
The architect is responsible for the geometry and layout cf
the spaces as we 11 as the specification of the materia Is of
the walls and other surfaces; the structural engineer is
res pons ible for the structural f ram.-? r mm i r^ d to sunrort the
loads in the building; the electrical engineer for the
distribution of electrical power throughout the building as
required; the mechanical engineer for the system of air
ducts for the delivery of hot and col'* air to the spaces and
the removal of waste air from the system. Each of these
designers has a realm of data which he develops in
conjuction with the objectives and requi rements o^ th *
others connected with the project.
Thus, while the architect generally has the principal
concern with windows as an element of form, his decisions on
windows greatly Influence the heat loads that ar^ the
responsibility of the mechanical engineer and the amount of
lighting which is the responsibility of the electrical
The file structure for a computer based information
system of building design data must be organized around the
use of data by the various agents primarily concerned with
that data, and the data within a file should be structured
in such a way as to reflect the relational an 1 algorithmic
structure of the data. The data regarding windows s^o-ild be
the responsibility of the architect. He is the designer
primarily responsible for choosing the quality and location
OOC ic 2
^ui o J-
OO H flc
mO. UJ q
-J a 2
K s 2:
uj < cc
H J O
< w .
S ^t ^
O H OS
of windows. Also the location of Information about thr?
windows among all of the lata Items which fall into tbe
realm of the architect should reflect the fact that windows
are located in walls, walls which delimit two spaces.
With a file so structured, the mechanical engineer in
doing heat load analysis can interrogate the data base of
the architect regarding the room under consideration, asking
for the U-factors for each of the walls and be told that a
particular wall has a window of some specific size and that
the design temperature minimum on the other side of that
window during the window is -20 degrees Fahrenheit,
Furthermore, the electrical engineer can query the same file
of the architect and learn that the room has a window with a
southern exposure and hence has a calculable flux of
The macro level file structure proposed for a
building environment Is outlined in Figure l-U. This
represents a first effort at a file structure of this sort.
As work proceeds, further refinements on the various
sub-files and their relationships will become apparent.
1. See especially/ Roos, Daniel, £_i., I CES System , Genera 1
Descr i pt ion , Report R 67-4 9, Depart nent of Civil Engineering
(Cambr i dge : Massachusetts Institute of Technology, 19*57),
and Jordan, Jane, £d.., I CES System , Programmers Reference
Manual , Report R67-5 0, Department of Civil Engineering
(Cambr i dge: Massachusetts Institute o c Technology, 19 3 7).
2. Among the subsystems of ICES are several that are of
particular concern to the realm of building .lesion and
construction. These are the STRUDL subsystem, tha PROJECT
subs y stein, the TABLE subsystem, and the TU I ID subsystem.
Cf: Logcher, Robert D., £JL al. , ICES STRUDL - 1 I, The
Structural Oesi gn Language : Engi neeri ng User's Manual , First
ed i t ion, Report R68-T1, Department of Civil Engineering
(Cambridge: Massachusetts I nst i tute of Techno 1 oey, 19-58 ) ;
Logcher, Robert D., and James N. Jackson, ICES TA3LE -I I : hH
ICES File Storage Subsystem : Engineer ing User's Manual ,
First edition, Report R69-3*+, Department of Civil
Eng i neeri ng ( Cambr i dge: Massachusetts Institute of
Technology, 1969); Daniels, Robert L., and E. Jack Mall,
I CES PROJECT - I I , Project Eng i neeri n.g Control : General
Descri ot i on . Second edition, Reoort R68-11, Department of
Civil Engineering (Cambr i dge: Massachusetts Institute of
Technology, 1968); and Teague, Lavette C. , £JL a±. , A User f s
Gu i de to BUI LP , Department of Civil Engineering (Cambridge:
Massachusetts Institute of Technology, 1957
3. Roos, Daniel, I CES System Design , Second edition
(Cambridge: MIT Press, 1967).
b. A relational data structure, as opposed to a structure
based only on data arrays, is one that represents in the
computer memory not only data val ues but also data
rel at i onshi os and st ructure . This is generally accomplished
by the addition of pointer capabilities to the array feature
i n order to represent the relations.
5. Lipner, S. B., "A List Processing System for Engineering
Applications, 11 IM. S. thesis submitted to the Department of
Civil Engineering, Massachusetts Institute of Technology,
6. Roos, ICES System Design , Appendix M.
7. Long, Richard, "Data Transfer In Large Scale Computer
Systems, 11 (unpubl ished Master's Thesis, Sloan School of
Management, Massachusetts Institute of Technology, 1963).
3. "Growing Popul at ion + rjrowi ng Needs = Soaring
Construction/ 1 Construction M ethods , July, 19U6, p. 26.
9. Ibid ., p. 27.
10. Dietz, A. G. H . , The Bui Iding Industry , A report
prepared for the Commission on Urban Problems, March, 1968.
Available from Clearinghouse, PB185208.
11. Ministry of Public Buildings and Works, Profess ional
CQllabQratlQn la Designing BuMdinKS/ R * n Bui Ming
Management Handbook, 5 (London: Her Majesty's Stationery
12. Miller, Charles L., "Decision Makers, 11 Intervipw with
Charles L. Miller, Computer Decisions , February, 1970, po.
13. For comparative i nformat ion on comouter capacity and
performance, see Auerbach Info., Inc., Auerbach Standard Epp
Reports (Philadelphia: Auerbach Info., Inc., 1969).
Ik. Computerworld , May 2n, 1970, p. 1.
DOCUMENT CONTROL DATA - R&D
(Security claaailication of title, body of at at red and interning annotation muat be entered when the overall report ia claaaitied)
1. ORIGINATING AC Tl VI T Y ( Corpormtm author)
Massachusetts Institute of Technology
Zm REPORT SECURITY CLASSIFICATION
3. REPORT TITLE
Interactive Design Coordination for the Building Industry
4. DESCRIPTIVE NOTES (Type ot report and incluaive dote a)
S. AUTHOR(S) (Leaf name, tirat name, initial)
Jackson, James N.
6. REPORT OATE
June 22, 1970
8a. CONTRACT OR GRANT NO.
ft. PROJECT NO.
7«. TOTAL NO. OP PAGES
76. NO. or RCPS
9a. ORIGINATOR'S REPORT NUMBER(S)
9b. OTHER REPORT NO(8) (Any other manbara that may be
aaelgned thia report)
10. AVAILABILITY/LIMITATION NOTICES
Distribution of this document is unlimited.
II. SUPPLEMENTARY NOTES
SPONSORING MILITARY ACTIVITY
Advanced Research Projects Agency
Washington , D # C .
One of the responses to the need for effective interaction in the
use of computers for a design project is the supersystem concept
proposed for ICES, the Integrated Civil Engineering System. The
supersystem is defined as the cooperative effort on the part of the
designers of several problem oriented computer capabilities to
implement project oriented capabilities by allowing each of, their
problem oriented subsystems to reference a single file of project
data. The supersystem would allow design interaction by having each
of the problem oriented computer subsystems reference a single file
of information specifying the project.
Future work in the application of computers to interactive and
project oriented design in the building industry will have to
concentrate on the file structure to be used in the implementation of
— a computer building design oupc r gyafec t n.
14. KEY WORLDS
Computers, Building design, Building construction, ICES System,
1 NOV ••